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PREFACE 


Promising  research  results  from  AL/HRGA’s  Information  Integration  for  Concurrent 
Engineering  (IICE)  program  prompted  Armstrong  Laboratory  management  to  expand  the  scope 
of  planned  IICE  technology  demonstration  and  testing  activities  to  include  their  application  to 
the  Air  Logistics  Center  (ALC)  environment.  The  Oklahoma  City  Air  Logistics  Center  (OC- 
ALC),  located  at  Tinker  Air  Force  Base  (AFB),  Oklahoma,  was  chosen  as  the  site  for  this  work. 
As  one  of  the  five  major  ALCs  within  the  Air  Force,  Tinker  AFB  offered  a  unique  environment 
for  fully  testing,  under  Armstrong  Laboratory  management,  the  effectiveness,  robustness,  and 
scalability  of  the  emerging  IICE  technologies. 

The  intent  of  the  work  reflected  in  this  report  was  to  leverage  IICE  advanced  developments  in 
direct  support  of  OC-ALC  Programmed  Depot  Maintenance  (PDM)  planning  and  scheduling 
needs.  The  results  of  this  work  revealed  both  the  ease  and  effectiveness  with  which  the  IICE 
technology  can  be  brought  to  bear  on  a  situation,  and  the  further  potential  that  this  technology 
and  its  application  provide. 
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INTRODUCTION 


Global  economic  pressures  and  the  perception  that  our  nation  no  longer  needs  a  large  military 
production  base  have  motivated  downsizing  measures  and  conversion  strategies  aimed  at 
sustaining  military  readiness  while  simultaneously  improving  competitiveness  in  the  global 
commercial  arena.  For  OC-ALC,  these  changes  have  implications  for  both  their  way  of  doing 
business  and  the  size  and  composition  of  their  workforce. 

From  an  enterprise  operations  perspective,  OC-ALC  is  faced  with  the  challenge  of  evolving  from 
a  “just-in-case”  environment,  for  which  the  ALCs  were  originally  designed,  to  an  environment 
that  manifests  the  new  “just-in-time”  economy.  That  is,  OC-ALC  is  being  challenged  to 
demonstrate  their  cost,  on-time  delivery,  and  quality  performance  in  a  more  highly  charged, 
competitive  environment.  Even  large  end-item  maintenance  workload,  previously  the  sole 
purview  of  the  ALCs,  has  begun  to  be  challenged  in  open  commercial  competition.  For  example, 
at  Tinker  AFB,  a  significant  percentage  of  the  E-3  Programmed  Depot  Maintenance  (PDM) 
workload  was  competed  for — ^the  potential  first  of  many  future  commercial  contracts.  Having 
won  the  award.  Tinker  AFB  was  forced  to  begin  the  task  of  converting  to  dual-use  operations  on 
the  E-3  PDM  line.  That  is,  OC-ALC’ s  management  was  challenged  with  making  improvements 
to  the  PDM  line,  and  re-orienting  current  practices  to  support  both  contract  (commercial  sector) 
and  organic  (public  sector)  operations  using  the  same  people,  facilities,  equipment,  and 
information.  These  needs  also  came  amidst  demands  to  shorten  PDM  cycle-time  and  improve 
flexibility,  responsiveness,  and  economy. 

From  a  defense  workforce  perspective,  OC-ALC  is  faced  with  the  challenge  of  maintaining 
critical  capabilities,  knowledge,  and  experience  amidst  large  reductions  in  force  and  widespread 
worker  displacement.  Thus,  there  is  a  growing  need  for  methods  and  tools  to  minimize  or  avoid 
the  loss  of  critical  corporate  knowledge  and,  consequently,  operational  readiness. 

A  number  of  factors  influenced  the  Air  Force’s  decision  to  pursue  an  IICE  technology 
application  demonstration  effort  that  supports  Programmed  Depot  Maintenance  (PDM)  planning 
and  scheduling  processes.  First,  aircraft  PDM  is  the  primary  workload  of  OC-ALC.  It  is  also  the 
largest  workload.  Improvements  to  the  processes  supporting  this  workload,  therefore,  offers 
more  payback  potential.  Further,  existing  systems  often  provide  limited  support  in  areas  required 
to  effectively  plan  and  schedule  PDM  activities.  Since  these  support  processes  and  systems 
largely  determine  the  degree  to  which  measures  of  OC-ALC  performance  can  improve,  the  Air 
Force  thought  that  improving  PDM  planning  and  scheduling  processes  would  yield  the  greatest 
positive  impact. 


PROJECT  OBJECTIVES  AND  SCOPE 

The  purpose  of  this  effort  was  to  demonstrate  the  potential  of  the  IICE  technologies  to  facilitate 
simultaneous  process,  information,  technology,  and  cultural  change.  The  selected  areas  of 


demonstration  were  the  planning  and  scheduling  systems  supporting  E-3  PDM.  The  following 
five  key  objectives  framed  the  effort  undertaken  at  OC-ALC: 

1 .  Demonstrate  ways  that  the  IICE  technologies  can  enhance  OC-ALC  personnel’s 
capability  to  plan  and  schedule  the  PDM  process. 

2.  Develop  a  prototype  system  designed  to  help  users: 

a.  reduce  the  overall  lead  time  of  the  E-3  PDM  process. 

b.  improve  the  responsiveness  of  the  E-3  PDM  support  processes. 

c.  improve  the  accuracy  of  projected  resource  and  material  needs. 

d.  improve  the  realization  of  promise  dates. 

e.  reduce  the  number  of  discrepancies  during  the  final  post-doc  test. 

f  reduce  the  amount  of  unplanned,  vmscheduled,  and  over-and-above  tasks  in  the  E- 

3  PDM  process. 

g.  improve  the  speed  and  accuracy  of  bid  package  preparation. 

h.  access  decision  support  tools  and  existing  systems  so  they  can  focus  on  aircraft 
maintenance,  not  information  technology. 

i.  enhance  communication  with  other  gateways,  allowing  access  to  technical  and 
historical  information. 

j.  accurately  assess  the  effectiveness  of  the  IICE  products  with  an  eye,  toward 
establishing  an  organic  capability  in  continuous  process  improvement. 

3.  For  a  select  set  of  maintenance  operations,  develop  an  operational  level  process 
description  to  demonstrate  how  the  IICE  IDEF3  Process  Description  Capture  method 
can  be  used  to  maintain  operation-level  precedence  constraint  information. 

4.  Develop  a  high-level  simulation  model  of  the  E-3  PDM  process. 

5.  Develop  an  E-3  PDM  Bar-code  Game  Plan  along  with  an  information  model  and 
prototype  database  to  guide  the  development  of  a  system  to  collect  shop  floor  actuals 
using  bar-code  technology. 

Given  the  broad  range  of  objectives  outlined  for  the  effort,  our  most  difficult  challenge  was  to 
establish  the  scope  of  the  reengineering  and  development  effort.  That  is,  it  was  vitally  important 
that  the  range  of  systems  and  processes  targeted  be  carefully  chosen  to  maximize  positive  impact 
while  still  addressing  project  objectives.  For  example,  although  depot  maintenance  includes 
repair  and  remanufacturing  activities  in  the  back  shops,  most  of  the  effort’s  emphasis  was  placed 
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on  large  end-item  maintenance.  Therefore,  items  routed  to  the  back  shops  were  treated  largely  as 
“black-box”  processes.  We  also  identified  areas  where  entire  processes  appeared  to  be  missing, 
support  was  inadequate  or  entirely  lacking,  there  was  significant  potential  for  positive  impact, 
and  leverage  could  be  gained  through  cooperative  effort  with  other  initiatives. 

The  OC-ALC  Systems  Environment 

Supporting  today’s  PDM  process  is  an  extensive  network  of  data  systems  that  govern  OC-ALC 
maintenance  operations.  In  all,  over  thirty  individual  systems  comprise  the  depot  maintenance 
data  systems  network.  These  systems  range  in  functional  responsibility  from  material 
requirements  projection  to  inventory  tracking  and  maintenance  operations  planning  to  expense 
reporting.  Each  has  evolved  semi-independently  to  serve  the  needs  of  their  respective 
communities.  The  cumulative  result  is  a  patchwork  of  old  and  new  systems  that  perform  a  wide 
range  of  data  collection,  monitoring,  and  control  activities. 

Today’s  depot  maintenance  data  systems  struggle  to  meet  requirements  for  new  levels  of  OC- 
ALC  infrastructure  agility,  responsiveness,  and  economy.  Increasingly,  the  explosive  rate  of 
change  to  which  these  systems  must  adapt  makes  it  difficult  for  OC-ALC  organizations  to 
improve  their  flexibility,  response  time,  quality  and  reduce  their  costs.  Among  the  symptoms 
that  point  to  a  growing  gap  between  critical  OC-ALC  processes  and  their  automated  support 
systems  are  the  following  items. 

1 .  Process  owners  do  not  own  their  process  data.  Process  owners  must  frequently  go  to 
at  least  one  other  organization  to  simply  gain  access  to  data  critical  to  their  process. 
Having  no  ownership  of  the  data,  users  are  often  forced  to  change  code  to  get  a 
different  perspective  of  their  data.  For  example,  existing  and  projected  material 
availability  information  is  the  most  important  resource  information  required  by  E-3 
planners.  This  information  is  maintained  by  a  separate  organization  and  is  largely 
unavailable  to  planners. 

2.  Accessible  data  is  often  unusable.  Data  collection  systems  often  maintain  only 
summary  level  information,  rendering  this  information  largely  unusable  to  all  but  high- 
level  management.  For  example,  PDMSS  provides  a  valuable  summary-level 
projection  of  planned  maintenance  activities.  Since  the  projection  is  made  using  high- 
level  estimates  of  resource  availability  (e.g.,  material,  manpower,  facility)  with  only 
limited  consideration  of  constraints,  these  projections  are  rarely  useful  for  day-to-day 
scheduling  and  dispatching  activities. 

3.  Users  often  feel  compelled  to  circumvent  data  systems.  As  the  pace  and  scope  of 
process  change  accelerates,  software  maintenance  and  development  backlogs  (usually 
into  months  or  even  years);  meanwhile,  users  devise  innovative  ways  to  apply 
command  data  systems  to  at  least  partially  support  activities  that  the  systems  are  not 
designed  to  handle.  When  this  occurs,  data  available  to  downstream  users  becomes 
increasingly  suspect  and/or  unavailable.  For  example,  E-3  planning  personnel 
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developed  an  elaborate  system  of  codes  that  they  used  to  extend  or  change  the 
functionality  of  their  primary  planning  system,  G037E. 

4.  Data  systems  drive  the  process  and  stifle  positive  change.  Policies  aimed  at  ensuring 
that  downstream  data  users  get  the  data  they  require  creates  an  environment  in  which 
data  systems  become  the  masters  and  the  users  their  slaves.  When  this  flip-flop  occurs, 
creativity  and  innovation  give  way  to  subservience  in  satisfying  data  system  needs  at 
the  expense  of  user  needs.  For  example,  G037E  calculates  a  critical  path  and  generates 
a  schedule  for  dispatching  operations  to  the  shop  floor  after  planners  group  and  link 
each  of  the  operations  in  the  E-3  planning  data  set.  With  between  9,000  and  12,000 
operations  typically  planned  for  each  E-3  undergoing  depot  maintenance,  it  is  clearly  a 
daunting  task  to  study  and  document  the  relationships  between  each  individual 
operation  in  the  set.  In  fact,  to  do  so  puts  an  unnecessary  strain  on  the  range  of  possible 
schedules  that  can  be  implemented  on  the  shop  floor. 

The  impact  of  these  gaps  between  critical  OC-ALC  processes  and  their  automated  support 
systems  creates  a  number  of  problems,  some  of  which  are  listed  below. 

1 .  OC-ALC  performance  indicators  provide  unreliable  (even  misleading)  feedback  and 
limited  management  visibility. 

a.  Actual  hour  accounting,  material  usage,  and  real-time  task  status  information  is 
unreliable  or  unavailable. 

b.  Shop  efficiency  ratings,  bottlenecks  in  resource  availability,  and  the  lack  of 
reliable  shop  floor  dispatching,  scheduling,  and  control  systems  combine  to 
produce  counterproductive  behavior. 

2.  There  is  a  general  lack  of  integration  between  aircraft  maintenance  activities  and  PDM 
support  systems  and  processes. 

3.  There  is  a  heavy  reliance  on  stand-alone  public  domain  and  special-purpose  proprietary 
systems  whose  cost-competitiveness  and  functionality  have  been  surpassed  by 
commercial-off-the-shelf  (COTS)  packages. 

4.  Planning  and  scheduling  of  Programmed  Depot  Maintenance  (PDM)  resources  is  labor- 
intensive,  time-consuming,  and  unreliable. 

a.  There  are  currently  no  automated  tools  to  make  operation  level  economies  visible 
to  plaimers,  schedulers,  and  supervisors.  For  example,  lacking  an  explicit  factory- 
level  schedule  promotes  the  occurrence  of  multiple  access  and  button-up 
operations  on  the  same  panel. 

b.  Currently  available  automation  support  for  time-phased  operations  scheduling, 
need-date  estimating,  and  resource  contention  resolution  is  extremely  limited. 
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c.  There  is  no  automated  support  for  contingency  planning,  analysis,  and  decision 
supp>ort. 

d.  There  is  no  automated  support  for  assessing  the  impact  of  shared  facilities, 
equipment,  personnel,  and  material  on  the  PDM  schedule. 

e.  No  support  is  provided  to  improve  PDM  process  predictability  through  the  early 
identification  of  “over-and-above”  workload  (over-and-above  tasks  account  for 
20-35%  of  the  work  performed  during  PDM). 

Production  Maintenance  versus  Production  Manufacturing 

Closing  the  gap  between  critical  OC-ALC  processes  and  their  automated  support  systems 
requires  more  than  simply  updating  what  is  currently  available  with  new  technology.  In  fact, 
introducing  new  technology  in  hopes  of  solving  problems  often  results  in  exactly  the  opposite 
result.  Many  correctly  parrot  the  familiar  axiom  that  processes  and  systems  must  be 
“reengineered”  or  “integrated”  first.  Only  then  should  new  automation  strategies  be  applied. 

This  is  very  true,  particularly  in  the  OC-ALC  environment,  where  informal  practice  has 
necessarily  evolved  to  work  around  an  overconstrained  or  poorly  suited  system.  Central  to  the 
task  of  reengineering  is  understanding  the  nature  of  the  process  or  system  to  be  reengineered. 
That  is,  one  must  first  recognize  those  features  that  distinguish  one  environment,  which  is 
amenable  to  the  application  of  one  set  of  design  principles  or  paradigm  of  operation,  from 
another. 

The  OC-ALC  depot  maintenance  environment  is  one  that  poses  some  subtle  and  unique 
challenges  that,  if  overlooked,  can  lull  process  designers  and  system  developers  into  choosing  a 
systems  paradigm  that  operates  poorly,  or  not  at  all.  The  unique  demands  placed  on  depot 
maintenance  planning  and  scheduling  systems  create  a  number  of  critical  differences  that  require 
different  strategies  from  those  traditionally  applied  to  the  production  manufacturing 
environment.  Critical  differences  between  the  production  maintenance  and  the  production 
manufacturing  environments  require  entirely  different  methods,  processes,  and  systems.  In  spite 
of  these  critical  differences,  many  of  today’s  OC-ALC  systems  were  designed  and  built  under  the 
assumption  that  the  depot  maintenance  environment  behaves  just  like  a  production 
manufacturing  facility. 

There  are  three  distinguishing  characteristics  that  make  planning  and  scheduling  aircraft 
maintenance  activities  uniquely  different  from  aircraft  manufacturing.  First,  access  constraints 
are  negligible  in  an  aircraft  manufacturing  environment,  whereas  these  constraints  have  a 
significant  impact  on  maintenance  planning  and  scheduling.  Aircraft  undergoing  depot 
maintenance  are  only  partially  disassembled  through  the  process,  making  it  important  to  consider 
how  to  1)  protect  the  structural  integrity  of  the  aircraft  while  it  is  being  worked  on,  2)  provide 
enough  room  to  work,  and  3)  coordinate  different  classes  of  maintenance  activity  in  the  same 
areas.  Second,  in  maintenance  environments,  only  a  partial  ordering  of  activities  can  be 
developed.  In  the  manufacturing  environment,  however,  a  firm  sequence  of  operations  can  be 
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established  since  the  work  content  is  determined  by  the  assembly  requirements  of  the  product. 
Finally,  the  bill  of  material  is  known  up  front  in  manufacturing  environments,  whereas  it  is 
largely  unknown  in  a  maintenance  setting. 

Typical  of  production  manufacturing  planning  and  scheduling  systems,  today’s  OC-ALC 
maintenance  and  material  management  systems  presume  that  the  bill  of  material  (required  for 
maintenance)  and  associated  labor  content  can  be  determined  beforehand  (i.e.,  is  predictable). 
Historical  patterns  at  the  OC-ALC,  however,  demonstrate  that  between  20%  and  35%  of  depot 
maintenance  work  content  is  unpredictable  or  “over-and-above.”  Further,  the  prediction  methods 
used  by  today’s  plarming  systems  to  project  future  spares  and  reprocurement  needs  assume  that 
one  can  accurately  predict  future  requirements  by  analyzing  past  usage.  For  predictable  items 
(i.e.,  spare  parts  whose  replacement  rates  are  relatively  constant),  the  assumption  that  past 
material  patterns  will  closely  approximate  future  material  requirements  is  perfectly  legitimate. 
However,  only  about  20%  of  the  items  managed  by  the  depot  material  management  system  are 
considered  predictable  items.  Fortunately,  those  items  supply  the  material  for  most  depot 
maintenance  work  (65-80%  of  depot  workload).  The  remaining  80%  of  maintenance  material 
items  fall  into  the  unpredictable  group  (see  Figure  1).  This  means  that  as  much  as  a  third  of  all 
aircraft  maintenance  material  needs  are  unpredictable. 

As  the  aircraft  ages,  the  frequency  of  unpredictable  and  over-and-above  work  (e.g.,  through  the 
discovery  of  cracks  and  corrosion)  increases,  adding  further  complications.  This  phenomenon 
serves  to  both  raise  the  OC-ALC’s  depot  maintenance  workload  and  increase  the  ratio  of 
unpredictable  to  predictable  work. 

One  consequence  of  this  phenomenon  is  that  schedules  based  on  a  predetermined  set  of  tasks 
with  a  presumed  duration  rapidly  become  obsolete,  often  with  the  first  discovery  of  over-and- 
above  work.  This  is  precisely  the  situation  present  in  today’s  PDM  scheduling  support  systems, 
which  use  a  critical  path  algorithm  to  produce  a  schedule  of  depot  maintenance  activities.  The 
critical  path  is  determined  by  the  amount  of  time  required  to  perform  individual  operations  as 
specified  by  labor  standards.  Calculation  of  the  critical  path  also  requires  establishing  a 
completely  linked  network  of  operations,  or  groups  of  operations,  at  the  level  where  the  critical 
path  will  be  calculated.  And  yet,  material  acquisition  lead  time,  access  constraints,  and  resource 
leveling  requirements — ^none  of  which  are  considered  by  the  traditional  critical  path  algorithm — 
determine  what  level  of  schedule  compression  can  be  achieved.  In  this  environment,  critical 
path-based  schedules  lose  their  utility  as  a  plan  for  daily  activity  and,  consequently,  their 
reliability  as  a  predictor  of  on-time  delivery  performance. 

The  distinction  between  production  maintenance  and  production  manufacturing  systems  became 
very  important  as  the  IICE  team  worked  to  provide  viable  solution  concepts  for  PDM  planning 
and  scheduling. 
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Increase  in  Aircraft  Age 


Unpredictable  Work 
Predictable  Work 
Actual  Maintenance  Workload 
Bill  of  Materials 


Figure  1 

Unpredictable  Workload  Creates  Requirements  Computation  and  Scheduling  Uncertainty 


APPROACH 

With  this  scope  in  mind,  a  model-driven  approach  to  requirements  definition  and  prototype 
system  development  was  outlined  (see  Figure  2).  Any  undertaking  of  this  kind  requires  the 
concerted  effort  of  personnel  with  many  different  kinds  of  skills  and  experience.  For  this 
purpose  alone,  the  IICE IDEF  methods  proved  to  be  useful.  Each  method  provided  clear 
foundations  that  guided  knowledge  acquisition,  analysis,  and  design  activity.  This  also  provided 
a  common  framework  for  information  capture,  organization,  and  communication  among  analysts, 
developers,  and  domain  experts.  More  importantly,  the  methods  provided  an  effective 
mechanism  for  exploring  reengineering  opportunities  before  attempting  to  apply  automation. 

This  section  provides  a  description  of  the  approach  used  to  investigate  improvement 
opportunities  for  depot  maintenance  planning  and  scheduling.  Important  to  the  approach  taken 
was  the  use  of  the  IDEF3  Process  Description  Capture,  IDEF5  Ontology  Capture,  and  IDEF9 
Business  Constraint  Discovery  methods.  These  methods  were  applied  together  with  previously 
developed  IDEF  methods  (i.e.,  IDEF0  Function  Modeling,  IDEFl  Information  Modeling,  and 
IDEF  IX  Semantic  Data  Modeling  methods)  to  support  additional  analysis  and  design  decision¬ 
making  activities  and  to  demonstrate  how  the  IICE  methods  complement  previously  developed 
IDEF  methods. 
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Of  the  methods  applied,  IDEF3  and  IDEFl  were  most  extensively  used.  These  methods  were 
used  primarily  for  analysis,  requirements  definition,  and  To-Be  process  design.  IDEF3  was  used 
to  document,  analyze,  and  reengineer  planning  and  scheduling  processes.  It  was  also  used  as  the 
framework  for  a  self-maintaining  simulation  model  of  the  PDM  process.  The  IDEFl  Information 
Modeling  method  was  used  to  model  the  information  that  is  currently  managed  to  support 
planning,  scheduling,  and  monitoring  functions.  The  IDEFIX  Semantic  Data  Modeling  method 
was  used  to  translate  IDEFl  information  management  requirements  into  a  logical  database 
design  for  both  the  prototype  planning  system  database  and  a  bar-code  enabled  shop  floor  data 
collection  database. 


Other  IDEF  methods  were  also  applied.  For  example,  IDEF0  was  used  together  with  IDEF3  to 
help  scope  analysis  efforts.  It  was  also  used  as  a  data  collection  vehicle  for  those  situations  in 
which  timing  and  precedence  information  was  unavailable.  The  IDEF5  Ontology  Description 
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Capture  method  was  also  found  to  be  quite  useful  (particularly  during  the  early  stages  of  the 
project)  for  capturing  unique  terminology,  identifying  subtle  but  important  distinctions  made  by 
people  in  different  role  types,  and  uncovering  key  associations  that  could  assist  with  downstream 
process  reengineering  and  system  development  efforts.  Of  these,  the  most  obvious  manifestation 
of  IDEFS’s  utility  was  its  impact  on  the  design  of  the  user  interface  to  ProPlan.  By  using  IDEF5 
to  understand  the  key  terminology  used  in  the  domain,  the  ProPlan  user  interface  became  easy  to 
use.  The  IDEF9  Constraint  Discovery  method  was  also  used.  This  use  was  largely  limited  to  the 
procedure  component  of  IDEF9  since  the  graphical  language  component  of  the  method  was 
under  development  throughout  much  of  the  project.  Applying  the  prototype  IDEF9  procedure  to 
catalog  symptoms,  hypothesizing  correlations  to  probable  causes,  validating  those  correlations, 
and  identifying  both  enabling  and  limiting  constraints  helped  to  guide  reengineering 
developments.  For  example,  it  was  through  the  application  of  IDEF9  that  the  scope  of  the 
ProPlan  prototype  was  extended  to  include  support  for  E-3  work  specification  developers. 
Currently,  planners  and  work  specification  developers  use  entirely  different  systems,  although 
they  must  work  together  to  effectively  manage  a  wide  range  of  business  constraints  to  minimize 
costs  while  still  keeping  the  E-3  fleet  well  maintained.  Using  the  prototype  IDEF9  method 
served  to  drive  improvements  to  the  IDEF9  procedure  and  provided  a  test  bed  for  experimenting 
with  alternative  language  designs. 

Key  Approach  Elements  and  Innovations 

A  number  of  approach  elements  were  used  to  satisfy  the  key  objectives  of  this  effort.  These 
elements  are  shown  in  the  following  list. 

1 .  Model-driven  reengineering  and  application  development  approach  involving  the 

integrated  application  of  multiple  IDEF  methods. 

2.  Design  for  the  unique  requirements  posed  by  the  production  maintenance  environment. 

a.  Capture  and  consideration  for  accessibility  constraints. 

b.  Emphasis  on  maximizing  planning  and  scheduling  process  flexibility  and 
responsiveness. 

c.  Explicit  mechanisms  to  provide  early  notification  of  unplanned,  unpredictable, 
and  over-and-above  maintenance  requirements  (e.g.,  electronic  capture  and 
notification  of  shakedown  results). 

3.  Design  for  maximized  reuse  with  particular  emphasis  on  the  following  items. 

a.  Maintenance  requirements  (i.e.,  work  specifications,  work  specification  tasks). 

b.  Master  networks. 

c.  Tail-specific  plans. 
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d.  Operations  (including  over-and-above  operations  that  are  not  maintained  by 
today’s  systems). 

e.  Schedules. 

f.  COTS  software  components. 

g.  System  process  and  information  models. 

4.  Rapid  Application  Development  (RAD)  prototyping  strategy. 

a.  Use  of  component-based  systems  development  environments  (i.e.,  Digitalk  parts. 
Visual  Basic). 

b.  Incremental  builds  (three  versions). 

c.  Client/server  architecture. 

d.  Open  architecture  design. 

5.  Finite  capacity,  simulation-based  schedule  projection  and  analysis. 

a.  Self-maintaining  operation-level  E-3  PDM  simulation  model. 

b.  Simultaneous  generation  of  multiple,  resource-constrained  aircraft  schedules. 

c.  Elimination  of  the  need  to  perform  downstream  resource  leveling. 

d.  Reduced  data  input  burden  over  critical  path-based  methods  with  improved 
schedule  projection  reliability  and  flexibility. 

e.  Ability  to  mimic  multiple  scheduling  approaches  and  algorithms  using  tailorable 
operation  induction  strategies. 

Each  approach  element  was  designed  to  facilitate  a  model-driven  reengineering  and  application 
development  approach  to  successfully  address  a  highly  complex  set  of  problems,  rapidly  devise 
feasible  reengineering  solutions,  develop  automated  support  mechanisms  embodying  those 
reengineering  solutions,  and  provide  robust  prototype  systems  with  minimal  disruption  and  cost. 

Historical  Overview 

In  accordance  with  standard  IDEF  modeling  practice,  we  first  established  a  model  librarian 
function  where  source  material,  notes,  and  models  were  maintained  for  general  use  by  the  team. 
Project  material  configuration  control,  item  check-in/check-out,  review  kit  distribution  and 
management,  model  quality  management,  glossary  maintenance,  etc.,  are  a  few  of  the  activities 
performed  by  this  function. 
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Based  on  the  established  project  scope  and  working  with  OC-ALC  personnel,  we  then  set  out  to 
identify  the  key  processes  and  recurring  scenarios  that  comprise  the  planning  and  scheduling 
process.  Through  this  activity,  the  events,  activities,  and  processes  that  characterize  both  normal 
and  exceptional  situations  in  the  E-3  PDM  planning,  scheduling,  and  execution  were  identified 
and  categorized.  The  resulting  list  of  scenarios  was  then  used  to  further  refine  the  initial  project 
scope.  For  example,  only  a  select  set  of  scenarios  under  the  Execute  function  were  chosen  for 
subsequent  modeling  and  analysis.  This  list  of  scenarios  was  also  used  to  establish  data 
collection  and  analysis,  and  description  and  model  development  priorities. 

By  identifying  key  scenarios  associated  with  planning  and  scheduling,  we  were  also  able  to 
assess  the  frequency  and  relative  importance  of  different  parts  of  the  process.  For  example,  in  E- 
3  PDM  one  of  the  most  difficult,  time-consuming,  and  error-prone  processes  identified  was  that 
of  manually  identifying  and  typing  in  the  operations  to  be  applied  to  individual  tail  numbers. 
These  operations  were  based  on  tail-specific,  work  specification  task  call-outs.  With  literally 
thousands  of  operations  involved,  the  number  and  frequency  of  transcription  errors  are 
enormous.  These  transcription  errors  force  schedulers  to  spend  hours  each  week  poring  through 
stacks  of  computer  printouts  to  identify  and  resolve  avoidable  work  stoppage  problems  before 
they  happen.  By  simply  integrating  the  process  of  associating  work  specification  task 
performance  requirements  with  task  planning,  this  manual  process  was  entirely  eliminated. 

The  modeling  team  began  by  collecting  and  analyzing  formal  documentation  (e.g.,  command 
data  systems  documentation,  operating  instructions,  etc.)  describing  how  the  planning  and 
scheduling  systems  and  their  associated  processes  were  designed  to  operate.  The  formal  system 
was  then  modeled  using  IDEF3  modeling  and  IDEFl/lX.  Modeling  of  the  formal  system  was 
performed  iteratively  and  in  concurrence  with  modeling  efforts  that  captured  informal  processes. 

Onee  the  team  had  developed  a  small  representative  set  of  As-ls  formal  system  models  and  a 
postulated  set  of  models  representing  the  informal  process,  we  provided  informal  IDEF3  “in¬ 
context”  training  (i.e.,  training  provided  with  material  developed  using  actual  project  model  data) 
to  engage  OC-ALC  personnel  in  assisting  with  data  collection  and  validation  activities.  This 
approach  not  only  provided  an  effective  mechanism  for  accelerating  As-Is  model  development, 
but  also  served  to  involve  OC-ALC  personnel  in  the  genesis  of  concurrent  process  and  cultural 
change.  OC-ALC  personnel  involvement  was  also  critical  to  collect  reliable  time,  quality,  and 
cost  data  for  key  planning  and  scheduling  processes.  OC-ALC  personnel  involvement,  coupled 
with  the  IDEF  methods  and  tools,  helped  to  ensure  the  success  of  downstream  change 
conceptualization  and  simulation  activities  by  establishing  an  effective  mechanism  to  leverage 
the  knowledge,  intuition,  and  experience  of  domain  experts. 

Collecting  descriptions  of  the  informal  system  involved  the  identification  of  process  activities, 
their  inputs  and  outputs,  the  logical  ordering  of  activity  occurrence,  and  placement  of  decision 
points  and/or  branching.  The  IDEF3  method  was  used  extensively  for  this  task.  The  IDEF5 
Ontology  Capture  method  was  useful  during  the  initial  data  collection  and  analysis  phase,  where 
it  was  used  to  develop  an  understanding  of  the  terminology  associated  with  the  planning. 
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scheduling,  and  shop  floor  domains.  Key  relationships  within  and  between  respective  domains 
in  the  production  maintenance  enterprise  were  also  studied  by  collecting  and  studying  the 
associations  manifested  in  the  domain  terminology  base. 

While  modeling  the  relevant  OC-ALC  processes  was  generally  straightforward,  determining 
what  business  rules  are  actually  supported  and  enforced  by  the  information  system  was  more 
difficult.  Equally  difficult  to  discern  were  the  hidden  pockets  of  information  that  constitute  the 
“informal”  information  system  of  the  enterprise.  One  undertakes  information  modeling  to 
document  both  the  formal  and  informal  information  system.  The  IDEFl  information  modeling 
and  IDEE  IX  data  modeling  methods  were  particularly  useful  for  highlighting  the  existence  and 
structure  of  the  information  supporting  the  process.  The  resulting  models  were  used  to  establish 
the  foundations  for  evaluating  the  As-Is  information  system.  This  evaluation  focused  on  the 
adequacy  and  potential  contribution  to  the  management,  analysis,  and  improvement  of  the 
process. 

IDEFl /IX  served  predominantly  in  a  supporting  role  to  IDEF3,  being  used  to  display  and 
communicate  the  results  of  information  analysis  rather  than  as  a  direct  knowledge  capture  device. 
IDEF3  process  descriptions  served  as  the  primary  data  collection  vehicle  by  focusing  domain 
expert  attention  on  the  information  required  to  support  his/her  process.  This  approach  helped  to 
both  manage  information  modeling  activity  and  minimize  redundant  or  wasteful  effort. 

Interview  notes  and  representative  information  artifacts  of  the  process- (e.g.,  forms,  policy 
manuals)  were  collected  and  catalogued  by  the  modeling  team.  The  initial  As-Is  information 
models  were  developed  as  function-  or  process-view  information  models  typical  of  IDEFl/lX 
modeling.  A  “process-view  information  model”  constitutes  a  projection  on  a  comprehensive 
information  model,  displaying  only  those  entity  classes  that  are  involved  in  the  specific  activity 
of  interest. 

This  strategy  helped  to  organize  the  information  used  or  needed  to  support  specific  segments  of 
the  overall  process.  Likewise,  for  validation  purposes,  we  wanted  to  avoid  the  common  situation 
of  forcing  domain  experts  to  pore  over  wall  charts  searching  for  those  pieces  of  the  model  that 
applied  only  to  them.  This  strategy  also  served  to  minimize  the  chance  of  inadvertently 
prescribing  unnecessary  information  needs.  By  working  with  process-view  information  models, 
we  were  able  to  develop  an  unbiased  snapshot  of  today’s  information  systems.  Once  collected, 
individual  process-view  information  models  were  integrated  to  construct  a  comprehensive 
information  model  for  the  To-Be  system. 

Once  both  formal  and  informal  perspectives  of  the  E-3  PDM  planning  and  scheduling  processes 
had  been  captured,  the  team  set  out  to  analyze  those  processes  to  determine  what  was  right  about 
them,  what  was  wrong  about  them,  and  what  could  be  better.  Our  approach  involved  1) 
identifying  process  improvement  opportunities,  2)  formulating  candidate  To-Be  process  options, 
3)  exploring  the  feasibility  and  attractiveness  of  process  improvement  alternatives,  4)  selecting 
the  most  viable  option(s),  and  5)  rapid  prototyping  the  automation  support  mechanisms  for 
reengineered  processes. 
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Including  domain  experts  in  the  documentation  of  their  processes  involved  them  directly  in 
thinking  about  how  things  might  be  done  differently  (or  better).  An  interviewing  strategy  was 
used  as  part  of  a  knowledge-based  approach  to  elicit  observations,  intuitions,  and  experience 
from  domain  experts  about  the  recurring  scenarios  and  special-case  situations  encountered  in 
their  daily  work  activities.  This  interaction  with  both  the  owners  and  customers  of  the  process 
provided  additional  insights  (those  closest  to  the  process  often  develop  very  reliable  intuitions 
about  what  can  be  improved  and  how).  This  process  was  followed  by  more  in-depth  analyses, 
whose  purpose  was  primarily  to  support  the  development  of  To-Be  process  options.  IDEF9- 
supported  causal  analysis  was  applied  to  those  areas  showing  the  most  promise. 

The  main  goal  of  causal  analysis  was  to  identify  cause-and-effect  chains  affecting  the 
performance,  cost,  and  quality  of  a  given  process.  An  important  step  in  causal  analysis  is  to 
identify  constraints  between  the  objects  and/or  agents  in  the  system.  For  example,  the  following 
constraints  were  identified  for  the  E-3  PDM  (see  Table  1). 

The  basic  process  by  which  causal  analysis  is  accomplished  is  displayed  in  Figure  3  below. 
Causal  relationships  take  the  form  of  either  “enabling”  or  “limiting”  constraints.  Constraints 
encapsulate  the  assumptions,  policies,  and  procedures  of  an  organization  and  are  key  to 
understanding  relationships  between  the  different  components  of  a  system  and  the  whole  of 
which  they  are  a  part. 

Candidate  process  improvement  options  were  then  used  to  formulate  candidate  To-Be  processes. 
Recognition  of  the  unique  challenges  posed  by  the  production  maintenance  environment  was  key 
to  this  envisioning  process.  The  To-Be  process  formulation  method  applied  was  based  on 
fundamental  business  process  reengineering  guidelines,  such  as  those  depicted  in  Table  2. 

The  approach  to  To-Be  process  development  leveraged  reengineering  and  process  improvement 
techniques  to  identify  opportunities  for  both  incremental  and  large-scale  improvement 
opportunities. 

Incremental  improvement  techniques  attempt  to  institute  positive  change  while  maintaining  the 
basic  design  of  the  original  process.  This  kind  of  improvement  strategy  relies  heavily  on  domain 
expert  intuition  and  experience  to  streamline  processes,  eliminate  redundant  activities,  and/or 
speed  up  processes  through  automation.  This  approach  typically  produces  a  10  to  20% 
improvement  in  process  efficiency.  For  example,  in  response  to  feedback  from  E-3  planners,  the 
ProPlan  system  maintains  planning  data  for  low-percent  operations.  The  planning  systems 
currently  used  do  not  maintain  this  data.  By  simply  maintaining  planning  data  for  low-percent 
operations,  planners  no  longer  need  to  regenerate  operation  definitions  when  the  same  low- 
percent  operations  must  be  performed  on  another  aircraft.  Since  low-percent  operations  planning 
accounts  for  between  10  and  20%  of  the  total  planning  workload,  this  simple  feature  in  ProPlan 
produces  a  recognizably  significant  improvement. 
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Table  1.  Example  Constraints 


Examples  of  Constraints  Identified 

Impacts 

Material  required  to  perform  maintenance  on  a 
given  aircraft  caimot  be  ordered  until  30  days 
prior  to  its  arrival. 

Procurement  lead  times  often  far  exceed  30 
days.  Lacking  the  required  material  when  the 
work  needs  to  be  performed  causes  rob  backs, 
cannibalization,  and  schedule  delays. 

A  single  skill  (primary  skill)  must  be  identified 
for  each  operation. 

Operations  defined  at  a  level  of  granularity 
above  that  assigned  to  mechanics  often  call  for 
grades  that  exceed  what  is  required  to  perform 
some  or  most  of  the  work  specified.  Hence, 
mechanics  with  lesser  grades  or  within 
alternative  skill  categories  are  left  idle  when 
they  could  perform  much  or  all  of  the  work, 
while  mechanics  with  the  specified  skill  and 
grade  level  become  overused. 

The  E-3  must  share  one  of  two  paint  and  strip 
bays  with  other  aircraft. 

Schedule  compression  is  made  largely 
impossible  due  to  paint  bay  unavailability. 

Mechanic  can’t  order  material  until  he’s  taken 
the  operation  card. 

Mechanics  waste  considerable  time  preparing 
to  perform  an  operation  only  to  find  that  in 
many  cases  the  needed  material  is  not  available 
to  perform  the  operation. 

The  only  two  doors  large  enough  in  the  E-3 
hangar  to  bring  the  aircraft  in  and  out  are 
accessible  only  to  the  two  outside  bays  (of 
three  available). 

Aircraft  in  the  middle  bay  can  be  bottlenecked 
by  aircraft  on  either  side  of  them. 

E-3  operation  cards  are  released  on  a  schedule 
determined  from  anticipated  major  job 
durations. 

The  schedule  does  not  drive  shop  floor 
maintenance  activity  since  it  does  not  account 
for  over-and-above  work,  resource  constraints, 
etc.  Further,  shop  status  information  becomes 
misleading. 

E-3  shop  efficiencies  must  be  maintained  at 
acceptable  levels. 

Cherry  picking,  erroneous  reporting,  and  the 
hockey-stick  phenomena  all  occur  while 
providing  misleading  information  to 
management. 
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Figure  3 

Identifying  Constraints 


Table  2.  Basic  Guidelines  Used  for  To-Be  Process  Formulation 

Organize  processes  around  outcomes,  not  tasks. 

Have  those  who  use  the  output  of  the  process  perform  the  process. 

Identify  redundant  creation,  storage,  and/or  use  of  information. 

Subsume  information  processing  work  into  the  real  work  that  produces  the 
information. 

Capture  information  once,  at  the  source. 

Treat  geographically  dispersed  resources  as  though  they  were  centralized. 

Link  parallel  activities  instead  of  integrating  their  results. 

Put  the  decision  point  where  the  work  is  performed,  and  build  control  into  the 
process. 

Identify  portions  of  the  As-Is  process  that  exist  to  enforce  constraints  that  are  no 
longer  applicable. 

Eliminate  non-value-added  activities. 

Simplify,  consolidate,  streamline,  and  parallelize  value-added  activities. 
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In  contrast,  large-scale  improvement  techniques  seek  to  change  the  basic  model  of  doing 
business.  In  short,  these  techniques  search  for  opportunities  to  initiate  a  paradigm  change  that 
may  also  result  in  eliminating  entire  processes  and  the  artifacts  or  products  of  those  processes. 
For  example,  the  Stochastic  Resource  Requirements  Projector  (SRRP)  allows  users  to  develop 
candidate  schedules  that  automatically  enforce  constraints  on  resource  availability.  This 
capability  allows  for  the  entire  elimination  of  downstream  resource  leveling  aetivities  to  create  a 
feasible  schedule.  The  search  for  paradigm  change  opportunities  requires  looking  outside  the 
current  realm  of  experienee  to  identify  comparable  systems  or  processes  that  perform  the  same 
function  in  entirely  different  and  innovative  ways.  This  approach  often  generates  order-of- 
magnitude  improvements.  The  SRRP,  for  example,  enables  up  to  a  five-fold  improvement  in  the 
range  of  constraints  that  can  be  considered  simultaneously  while  developing  schedule 
projections.  The  SRRP  also  enables  users  to  produce  candidate  schedules  at  an  operation  level  in 
hours  rather  than  weeks,  as  currently  done. 

Once  alternative  To-Be  processes  were  formulated,  trade-off  analyses  were  performed  to 
evaluate  the  relative  merit  of  competing  process/system  design  alternatives.  Trade-off 
considerations  focused  on  the  impacts  of  change  with  respect  to  each  of  four  primary  areas: 

1 .  Cycle-time  performance, 

2.  Life-cyele  cost  performance, 

3.  Process  efficiency  versus  flexibility,  and 

4.  Localized  versus  global  effects. 

A  prime  example  of  the  above  considerations  is  embodied  in  the  design  approach  adopted  for  the 

SRRP.  One  of  the  initial  goals  identified  by  the  customer  was  to  provide  a  major-job-level 
simulation  model  using  the  data  available  through  the  current  set  of  OC-ALC  data  systems. 

While  developing  the  requirements  for  this  simulation,  the  processes  used  to  develop  schedule 
projections  were  documented  and  analyzed  for  potential  reengineering  opportunities.  We  soon 
concluded  that  the  existing  process  could  be  improved  significantly  by  increasing  the  level  of 
detail  fi'om  the  major  job  level  to  the  operation  level  while  leveraging  simulation  technology  to 
produce  feasible  schedules.  In  contrast  to  existing  methods  in  use  at  OC-ALC,  the  reengineered 
process  embodied  in  the  SRRP  produces  only  feasible  schedules,  thus  providing  more  reliable 
PDM  cycle-time  performance  data  to  decision-makers.  By  shortening  the  time  it  takes  to 
develop  schedule  projections  from  weeks  to  hours,  the  SRRP-based  process  also  provides 
significant  life-cycle  cost  gains.  The  SRRP-based  process,  unlike  the  G037E  schedule 
projection  process,  permits  planners  to  specify  only  those  constraints  that  must  be  maintained 
among  operations  in  a  given  schedule  (e.g.,  the  operation  to  open  an  access  panel  must  precede 
operations  performed  on  aircraft  components  physically  located  behind  the  panel).  This 
capability  promotes  the  development  of  schedules  that  enable  agile  operations  capable  of  rapidly 
shifting  to  alternative  schedule  paths  in  response  to  frequent  changes  in  known  maintenance 
requirements.  The  SRRP-based  process  also  provides  increased  visibility  on  the  impaets  of 
change  to  resomce  status  on  aircraft  maintenance  schedules  or  vice  versa.  For  example,  the  paint 
bay  is  critieal  to  E-3  PDM  and  to  other  aircraft  PDM  lines  (e.g.,  KC-135,  B-52).  A  change  in  the 
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scheduled  availability  of  the  paint  bay  can  have  significant  impact  on  E-3  PDM  cycle-time 
performance.  The  SRRP  technology  can  provide  rapid  what-if  analysis  results  as  well  as  provide 
alternative  strategies  to  deal  with  such  changes. 

The  To-Be  processes  were  then  used  to  develop  requirements  for  the  prototype  ProPlan  system, 
shop  floor  database,  and  scheduling  support  mechanisms  produced  as  software  demonstrations 
for  the  effort.  IDEF3  was  used  to  capture  a  To-Be  description  of  the  E-3  PDM  planning  and 
scheduling  processes.  Thus,  IDEF3  Process  Descriptions  served  to  define  the  process 
architecture  for  prototype  software  developments.  Additional  software  architectures  were  then 
defined.  These  included  function,  information,  module,  network,  and  menu  architectures.  The 
function  architecture  was  developed,  in  part,  through  the  use  of  IDEF0.  Textual  definition 
proved  to  be  more  time  efficient  for  this  task,  however. 

Information  architecture  development  was  accomplished  using  the  IDEFl  and  IDEFIX  methods. 
These  models  were  used  to  model  the  information  necessary  to  support  the  To-Be  processes  and 
provided  the  framework  for  designing  and  prototyping  the  system  database.  The  information 
model  development  task  explored  what  information  would  be  needed  to  monitor  and  control  the 
process,  what  information  would  be  used  by  the  process,  and  what  information  would  be 
produced  by  the  process.  Non-value-added  information  maintained  by  the  As-Is  information 
system  was  removed  in  the  To-Be  model.  For  example,  many  of  the  various  codes  used  by  E-3 
planners  to  facilitate  database-like  queries  on  the  flat  file-based  Workload  Planning  System 
(G037E)  were  eliminated.  This  was  made  possible  by  providing  the  mechanisms  to  perform 
both  predefined  and  ad  hoc  queries  on  the  ProPlan  database  without  having  to  rely  on  two-letter 
codes. 

At  the  same  time,  the  To-Be  model  included  newly  discovered  information  that  was  not  used  in 
the  “As-Is,”  but  which  was  deemed  critical  to  the  success  of  the  system  organization.  For 
example,  existing  planning  systems  in  use  at  OC-ALC  maintain  no  information  in  the  operation 
set  about  what  facilities  or  special  equipment  is  required  to  perform  the  work  specified.  The 
current  system  also  fails  to  maintain  information  about  accessibility  constraints.  These  are  both 
critical  to  capacity  planning  and  scheduling  activities.  This  and  other  value-added  information 
was  absent  in  the  existing  system  but  included  explicitly  in  the  developed  prototypes.  Module 
architecture  definition  involved  allocating  functions  to  system  components.  The  role  of  this 
activity  was  to  maximize  reuse  of  COTS  software  to  minimize  development  costs  and  reduce 
risk.  Several  COTS  components  were  incorporated  in  the  demonstration  prototype  including 
Microsoft  Word™  (document  processing),  Microsoft  Project™  (master  schedule  definition), 
Microsoft  ExceE*^  (operation  sorting,  reporting,  and  spreadsheet  preparation),  Microsoft 
Access™  and  Oracle™  (database),  WITNESS™  (simulation),  and  ProSim^m  (process  modeling 
and  WITNESS  code  generation).  The  network  architecture  was  developed  informally  at  both  a 
logical  and  physical  level  and  was  provided  to  OC-ALC  for  their  use  in  infrastructure  planning 
and  development.  Several  iterations  of  menu  architecture  definition  were  accomplished  using  a 
rapid  prototyping  approach  with  the  help  of  component-based  software  development 
environrnents.  As  the  structure  for  the  prototype  system  began  to  firm,  the  ProPlan  prototype 
was  ported  to  the  C++  environment. 
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The  resulting  software  was  then  demonstrated  and  tested  incrementally  by  developing  three 
versions  of  the  software.  Using  feedback  from  the  targeted  user  and  customer  communities,  the 
development  team  began  to  incrementally  narrow  and  refine  the  collection  of  To-Be  process 
improvement  recommendations.  This  turned  out  to  be  a  highly  repetitive  process  involving  the 
incorporation  of  domain  expert  feedback  into  the  process  and  prototype  system  design. 

The  most  visible  product  developed  was  the  prototype  planning  system  for  the  E-3  PDM  referred 
to  as  ProPlan.  Another  software  product,  the  SRRP,  was  designed  as  an  integral  component  to 
ProPlan  that  could  be  separated  out  as  an  independent  environment  for  the  E-3  PDM  schedule 
simulation  and  experimentation.  Working  with  ProPlan,  the  SRRP  provides  a  self-maintaining 
simulation  model  that  can  be  used  for  schedule  feasibility  testing  and  finite  capacity,  operation- 
level  schedule  generation.  Another  significant  product  was  a  prototype  shop  floor  data  collection 
database  and  shop  floor  information  system  mock-up.  This  product  was  referred  to  as  the  bar¬ 
code  game  plan  database  because  it  was  specifically  designed  to  leverage  bar-code  technology  in 
collecting  shop  floor  actuals.  The  context  for  use  of  these  software  products  will  now  be 
discussed. 


E-3  DEPOT  MAINTENANCE  PLANNING  PROCESS 

Programmed  depot  maintenance,  basically,  is  a  complete  physical  examination  and  partial 
restoration  process  for  aircraft.  Each  aircraft  undergoes  this  in-depth  scheduled  maintenance 
service  every  few  years.  Depot  maintenance  tends  to  be  far  more  extensive  in  breadth  and  scope 
than  field  maintenance.  Engineering  data  and  maintenance  data  from  the  field  assist  engineers  in 
determining  both  the  work  to  be  performed  and  the  interval  lengths  between  depot  maintenance 
events.  A  team  of  engineers  develops  the  initial  maintenance  requirements  as  a  written 
document — a  work  specification  that  outlines  the  work  requirement — and  aircraft  specific  work 
orders  (see  Figure  4).  Plaimers  take  this  work  specification  along  with  applicable  Technical 
Orders  (TOs)  to  define  work  instructions  (called  operations  and  definitized  lists)  for  the 
mechanic.  Planners  also  identify  the  nature  and  composition  of  the  resources  needed  to  complete 
each  operation  (e.g.,  skills,  material).  Schedulers  work  together  with  production  supervisors  to 
use  these  work  instructions  in  assigning  start  and  end  times  for  the  work  and  to  release  individual 
work  packages  to  mechanics.  Mechanics  then  perform  the  work  and  provide  feedback  to  the 
engineers  that  indicates  what  they  found  during  maintenance.  Engineers  then  take  this  feedback 
information  and  decide  future  years’  maintenance  requirements.  This  is  a  general  description  of 
the  depot  maintenance  cycle — many  other  details  have  been  omitted.  As  you  can  see,  each  group 
is  highly  dependent  on  the  other  groups  to  successfully  perform  their  duties. 

Engineers  group  similar  maintenance  work  by  programs.  Three  programs  for  the  E-3  are 
Analytical  Condition  Inspections  (ACI),  Analytical  Structural  Integrity  Program  (ASIP),  and 
Programmed  Depot  Maintenance  (PDM).  Within  each  program,  a  scoped  task  is  developed  by 
the  engineers.  Engineers  often  organize  tasks  by  similar  work  content  or  by  area  on  the  aircraft 
(e.g.,  tasks  performed  on  the  wings,  landing  gear).  Engineers  do  not  determine  labor  hours  or 
costs  involved  with  their  decision.  Ideally,  engineers  only  determine  requirements.  A  definite 
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work  breakdown  structure  is  present  in  work  specification  construction — i.e.,  the  progreim  has 
one  or  more  tasks,  which  may  also  be  further  subdivided. 


Work  Specification 
Tail  SpecificWork  Orders 


Engineers  (decide  WHAT  to  do 
A  based  on  feedback  &  tech,  docs.) 


Feedback  Results  from 
Inspections,  etc. 


Engineers/Planners  Meeting  (what  to  do 
within  budget  constraints) 

Work  Spec.  & 

Tail  Specific  Work  Order 


Mechanics  (perform  work  units 
and  report  maintenance  results) 


Planners  (define  work  units  and 
required  resources) 


Maintenance  Operations 
w/Resources  Documented 


Schedulers  (WHEN  to 
do  the  work) 


Figure  4 

General  Depot  Maintenance  Cycle 

Engineers  and  planners  then  negotiate  on  the  final  maintenance  requirements  after  feedback  is 
obtained  from  planners  concerning  the  labor  hour  cost  for  the  proposed  task.  Labor  estimates  are 
then  used  to  calculate  the  budget  required  for  that  year’s  depot  maintenance.  The  final  work 
specification  is  then  released  to  planning  for  the  maintenance  work  to  be  accomplished  during 
that  fiscal  year.  Accompanying  the  work  specification  is  an  aircraft-specific  work  order.  The 
work  order  lists  the  specific  required  tasks  to  be  performed  on  an  aircraft  for  that  fiscal  year. 

Planners  receive  this  document  and  compare  the  new  mainteneince  requirements  to  previous 
years’  work  specifications.  Often,  changes  are  not  needed,  but  any  different  maintenance 
requireihents  need  to  be  planned.  Some  tasks  may  change  only  slightly,  and  planners  need  only 
modify  an  existing  task  operation  set  to  effect  the  changes.  New  modifications  may  require 
planning  to  create  new  operations  to  modify  an  existing  aircraft  system. 
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When  an  aircraft  arrives  for  depot  maintenance,  the  appropriate  aircraft-specific  set  of  work 
specification  tasks  and  associated  operations  is  selected  from  the  generic  operation  set.  The 
aircraft-specific  operation  set  is  scheduled  based  on  precedence  information  supplied  by 
planners.  In  scheduling  and  dispatching  production  operations,  the  scheduling  system  takes  into 
account  the  current  state  of  aircraft  operation  completion,  precedence  constraints  among  the 
operations  to  be  performed,  accessibility  constraints,  and  current  and  projected  resource 
availabilities.  Production  mechanics  perform  the  operations  and  identify  additional  work  units 
while  performing  maintenance  inspections. 

The  prototype  ProPlan  system  developed  through  this  effort  supports  the  roles  of  engineer  and 
planner,  as  well  as  limited  scheduler  and  mechanic  functionality.  The  planner  role  is  heavily 
supported,  and  the  engineer  is  supported  by  assisting  with  the  creation,  modification,  and  reuse 
of  work  specifications  and  work  orders.  The  scheduler  is  supported  by  permitting 
experimentation  with  schedules.  The  mechanic  is  supported  by  providing  mechanisms  for 
describing  unpredictable  maintenance  requirements  and  communicating  those  requirements  to 
both  engineers  and  planners. 

PROTOTYPE  PROPLAN  PLANNING  SYSTEM 

ProPlan  is  a  prototype  software  system  that  supports  the  planning  and  scheduling  of  Programmed 
Depot  Maintenance  (PDM)  for  E-3  AWACS  aircraft.  It  is  an  open  architecture,  client/server 
system  with  embedded  COTS  software  that  provides  a  single  source  of  data  for  planning  E-3 
PDM. 

The  ProPlan  software  was  developed  using  a  Rapid  Application  Development  (RAD) 
methodology  incorporating  user-centered  design  principles,  multiple  IDEE  methods,  component- 
based  software  development  technologies,  and  a  rapid  prototyping  strategy  for  end-user  feedback 
and  verification. 

A  predominant  theme  used  throughout  ProPlan  software  development  was  reuse.  Reuse 
strategies  were  explored  with  respect  to  both  the  data  generated  and  used  in  the  environment  and 
with  respect  to  the  software  used  to  produce  the  prototype. 

There  were  a  number  of  opportunities  identified  to  provide  for  more  extensive  reuse  of  data 
generated  and  used  for  planning  and  scheduling.  For  example,  E-3  engineers  use  word 
processing  software  to  write  the  work  specifications  used  by  planners.  Included  in  the  work 
specification  is  a  work  order  which  displays,  in  matrix  form,  which  work  specification  tasks  are 
to  be  applied  to  which  tail  numbers.  Planners  are  then  given  a  printed  copy  of  the  work 
specification  and  the  included  work  order.  Individual  planners  then  design  a  set  of  operations  to 
address  each  task.  Before  mechanics  can  perform  the  work  specified,  however,  a  planner  must 
“tag”  the  generic  operation  set  maintained  within  G037E  with  the  specific  tail  numbers  that  are 
to  receive  that  work.  This  activity  requires  that  the  planner  print  out  all  the  operations  for  the 
workload  type  (e.g.,  organic,  contract,  foreign  aircraft,  sorted  by  work  specification  task), 
manually  highlight  the  tasks  to  be  applied  to  the  specific  tail  number,  and  then,  one-by-one,  “tag” 
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each  operation  in  G037E  with  a  special  code  tO  dispatch  the  work.  These  steps  could  be  entirely 
eliminated  by  putting  the  work  order  data  into  the  ProPlan  database  and  having  the  system 
automatically  sort  for  the  required  operations. 

Another  opportunity  for  reuse  was  evidenced  by  the  way  planners  worked  to  create  each  year’s 
set  of  plans.  E-3  planners  using  the  current  system  had  spent  years  developing  a  system  of 
special  codes  with  which  they  tagged  planning  data  to  permit  database-style  search  and  retrieval 
operations.  In  effect,  the  planners  had  converted  the  flat  file  systems  they  were  using  into  a  sort 
of  database.  They  did  so  by  first  conducting  a  manual  search  across  the  entire  operation  set 
while  concurrently  tagging  the  data  to  permit  automated  searches  in  the  future.  This  laborious 
work  reflected  their  practice  of  data,  whenever  possible,  making  modifications  to  existing 
operations,  rather  than  creating  operations  from  scratch.  Recognizing  this,  the  ProPlan  system 
was  designed  to  support  rapid  search  and  retrieval  operations  by  selecting  search  criteria  from 
pull-down  lists  representing  the  different  classes  of  information  maintained  about  operations. 
Operations  identified  through  this  simple-to-use  query  strategy  could  then  be  tailored  and  saved 
as  new  operations.  Similar  examples  of  data  reuse  support  could  also  be  enumerated. 

As  mentioned  before,  reuse  was  also  a  predominant  theme  in  the  software  development  activity. 
Much  of  the  ProPlan  software  is  actually  COTS  software  sewn  together  and  integrated  with  C++ 
code.  Among  the  COTS  packages  used  in  the  software  system  are  Microsoft’s  Word,  Excel, 
Project,  and  Access  products  together  with  Oracle,  AT&T  Istel’s  WITNESS  simulation  product, 
and  KBSI’s  ProCap  IDEF3  support  tool  (see  Figure  5). 


Work  Specs 


Operations 


Figure  5 

ProPlan  COTS  Components 
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A  client/server  architecture  was  used  for  the  hardware/software  eomponents  of  the  system.  This 
architecture  is  composed  of  a  single-server  local  area  network  (LAN),  connecting  IBM  PC- 
compatible  machines  running  the  Microsoft  Windows™  operating  system  (clients).  An  Oracle 
database  server  was  used  to  house  the  data  resident  to  ProPlan  and  is  accessed  through  a  Novell 
network.  ProPlan  clients  were  written  in  C++,  making  extensive  use  of  COTS  operating  in  a 
Microsoft  Windows  environment  (see 

Figure  6).  Since  ProPlan  was  designed  to  operate  in  a  distributed  environment,  it  includes 
mechanisms  for  concurrency  control. 


Novell  Network 


Figure  6 

ProPlan  Client/Server  Architecture 


The  following  includes  some  of  the  key  functions  supported  by  ProPlan. 

1 .  Maintenance  requirements  management  (i.e.,  work  specification  configuration  control 
and  management). 

2.  Assignment  definition  and  tracking. 

3.  Work  specification  development. 

4.  Operation  definition. 

5.  Resource  requirements  definition. 

6.  Depot  scheduling  (i.e.,  schedules  involving  all  aircraft  types  undergoing  depot 
maintenance). 

7.  Aircraft  maintenance  staging  definition  (i.e.,  facilities  flow). 

8.  Major  job  definition. 
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9.  Candidate  schedule  feasibility  testing.(at  an  operation  level). 

10.  Finite  capacity,  simulation-generated  scheduling  (multi-  or  single-aircraft,  operation- 
level  schedules). 

1 1 .  Capacity  planning. 

12.  Contingency  planning  (i.e.,  what-if  analysis). 

The  principal  groups  and  users  of  ProPlan  are  included  in  the  following  list. 

1 .  Planning 

a.  Planning  section  chief 

b.  Lead  planner 

c.  System  planner 

d.  Skill  planner/Task  planner 

2.  Production  Support 

a.  Section  chief 

b.  Engineer 

c.  Work  specification  developer 

d.  Project  administrative  official 

3.  Scheduling 

a.  Scheduling  section  chief 

b.  Material  expediter  (production  control  clerk) 

c.  Scheduler  (Expediter/Card  counter) 

One  of  the  key  components  of  ProPlan  is  the  Stochastic  Resource  Requirements  Projector 
(SRRP).  The  SRRP  is  a  separable  component  of  ProPlan  that  builds  its  own  simulation  model 
using  planned  operation  data  and  resource  availability  data  to  simulate  the  shop  floor.  It  can  be 
used  to  evaluate  planned  changes  to  E-3  PDM  or  to  generate  candidate  schedules  for  the  shop 
floor.  The  following  section  provides  a  more  detailed  discussion  of  the  SRRP. 
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STOCHASTIC  RESOURCE  REQUIREMENTS  PROJECTOR 


One  of  the  original  objectives  of  the  project  was  to  develop  a  major  job-level  simulation  model 
of  the  E-3  PDM  process.  Like  similar  models  developed  for  the  OC-ALC' prior  to  this  project,  . 
this  model  was  to  be  utilized  in  a  stand-alone  fashion  by  specially  trained  personnel  and  should 
answer  a  wide  variety  of  what-if  questions  concerning  labor  resourcing,  facility  utilization,  and 
maintenance  schedule  completion  projections.  Previous  efforts  modeled  an  aircraft  flowing 
through  a  particular  PDM  plan  depicted  as  a  large  major  job  network  (precedence  graph).  This 
approach,  while  excellent  for  answering  questions  concerning  the  specific  plan  that  was 
embedded  in  the  model,  makes  it  difficult  to  modify  the  model  to  analyze  alternative  plans.  ' 
Likewise,  the  simulation  models  built  in  this  way  produced  only  course-grained  results  for  a 
single  aircraft  maintenance  line.  Finally,  only  trained  simulation  modelers  were  able  to  use  or 
modify  the  resulting  models.  " 

In  contrast,  the  approach  used  to  develop  the  SRRP  makes  it  so  simple  to  use  that  E-3  planners 
lacking  simulation  modeling  experience  can  design  any  number  of  PDM  plans  and  utilize  the 
SRRP  to  evaluate  those  plans  under  the  dynamics  of  the  OC-ALC  environment.  Rather  than  the 
aircraft  “flowing”  through  a  particular  PDM  plan,  the  SRRP  treats  the  plan  as  input  to  the 
simulator  (not  the  aircraft).  The  operations  then  “flow”  through  the  aircraft  en  route  to  becoming 
“completed”  operations.  This  approach  allows  management,  engineers,  technicians,  and 
mechanics  to  evaluate  plan  designs  without  being  skilled  simulation  modelers.  This  approach 
also  enables  the  simulation  model  to  be  rapidly  and  easily  tailored  enabling  its  use  in  analyzing 
multiple  plans. 

This  data-driven  (or  black  box)  approach  treats  the  simulation  engine  as  a  component  that  has 
incorporated  a  design  robust  enough  to  handle  a  wide  variety  of  both  plan  sets  for  evaluation  and 
situation  characterizations  (profiles)  for  experimentation. 


serializing  rules 
Situation  profile 
Evaluation  profile 


Precedence  graph 


Evaluate 

PDM 

plan 


Performance  profile 


h  SRRP 


Figure  7 

SRRP  Data-driven  Design 
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Based  on  what  precedence  constraints  E-3  planners  identify  among  the  operations  used  to 
perform  a  given  work  specification  task  (assuming  those  constraints  exist),  the  ProPlan 
environment  constructs  a  precedence  graph  that  is  exported  to  the  SRRP.  The  SRRP  utilizes  this 
input  graph  or  graphs  for  multiple  aircraft  in  conjunction  with  user-supplied  sequencing  logic, 
situation  descriptions,  and  evaluation  criteria  to  provide  a  detailed  performance  profile  or  report. 
With  this  information,  the  SRRP  configures  itself  to  produce  a  simulation  model  that  accurately 
reflects  the  current  (or  experimental)  situation  (see 

Figure  8).  Thus,  simply  maintaining  the  operation  set  serves  to  maintain  the  currency  and 
relevance  of  the  simulation  model.  That  is,  maintenance  of  the  E-3  PDM  simulation  model  is  a 
side-effect  of  performing  normal  planning  functions.  The  SRRP  also  serves  to  support  E-3  PDM 
process  simulation  at  the  operation  level  rather  than  simply  at  a  major  job  level,  effectively 
increasing  the  reliability  and  accuracy  of  the  simulation  model. 
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Figure  8 

PDM  Simulation  Generation  Cyele  Using  the  SRRP 

The  SRRP  was  designed  to  assist  the  E-3  planner,  scheduler,  or  crew  chief  in  assessing  the 
effectiveness  of  remanufacturing  plans  developed  within  the  ProPlan  environment.  However, 
since  the  SRRP  simulation  was  developed  in  the  WITNESS  simulation  environment  (copies  of 
which  are  currently  used  and  owned  by  OC-ALC),  it  may  be  used  independently  of  ProPlan,  if 
desired.  The  SRRP  is  designed  to  ensure  its  immediate  application  to  other  weapons  systems. 
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The  SRRP  was  developed  and  released  in  incremental  builds  coinciding  with  those  of  the 
ProPlan  prototype.  This  ensured  that  the  SRRP  was  subject  to  a  continual  update  and  validation 
cycle  using  data  from  the  various  weapon  systems  at  the  base.  While  there  ^e  many  benefits  to 
the  strategy  and  tactics  employed  in  its  construction,  the  most  outstanding  benefit  of  the  SRRP  is 
its  simplicity  of  design,  thereby  enabling  its  use  by  a  variety  of  personnel  over  a  wide  array  of 
weapon  systems.  The  SRRP  employs  a  “black  box”  approach  for  the  simulation  engine  and 
reporting  capabilities.  This  approach  strives  to  achieve  a  “no  coding  required”  moniker,  while 
delivering  full-featured  plan  evaluation  to  the  user. 

The  implications  of  the  SRRP  technology  are  significant  for  the  E-3  production  maintenance 
environment.  In  the  depot  maintenance  environment,  the  ability  to  respond  rapidly  and  flexibly 
to  newly  identified  maintenance  requirements,  material  shortages,  contingency  situations,  and  so 
forth  is  of  critical  importance.  Scheduling  realignment  and  scheduling  impact  assessment  today 
is  a  laborious  and  very  time-consuming  task.  Proactive  change  management  necessitates  that 
schedules  be  generated  rapidly  using  all  available  resource  constraint  information  available. 

Since  resource  constraints  are  the  most  important  of  these,  the  scheduling  activity  must  not  only 
have  access  to  resource-related  information,  but  actively  leverage  this  information  as  well. 
Scheduling  development  and  change  impact  assessments  can  then  be  accomplished  in  real  time 
to  promote  proactive,  rather  than  reactive,  depot  maintenance  activity.  The  ability  to  conduct 
what-if  exercises  in  a  simulation-based  environment  further  improves  the  ability  of  decision¬ 
makers  to  plan  for  and  predict  material  needs  and  PDM  cycle-time  performance. 

As  a  finite  capacity  scheduling  system,  the  SRRP  uses  ProPlan  data  provided  by  planners  to 
account  for  a  wide  variety  of  resource  constraints  while  testing  or  generating  candidate 
production  schedules.  Material  resource  constraints  are  the  most  significant  of  the  constraints  to 
consider,  particularly  since  material  constraints  largely  determine  depot  maintenance  cycle  time. 
This  information,  however,  is  largely  inaccessible  to  those  engaged  in  the  depot  maintenance 
planning  and  scheduling  activity.  Thus,  both  today’s  scheduling  systems  and  the  SRRP  rely 
heavily  on  approximations  of  projected  material  availability  to  develop  schedule  predictions.  In 
spite  of  this  limitation,  the  SRRP  appears  to  provide  the  means  for  far  more  reliable  schedules 
and  schedule  predictions.  This  is  a  result  of  its  using  an  innovative,  simulation-based  approach 
enabling  rapid  candidate  schedule  generation  that  accounts  for  a  wider  range  of  scheduling 
constraints  and  probabilistic  situations.  In  contrast  with  critical  path  methods,  which  are  limited 
to  schedule  forecasting  based  solely  on  task  durations,  the  SRRP  has  the  ability  to  incorporate 
manpower  (i.e.,  skills),  equipment,  facility,  and  materials  constraints  that  often  supersede  the 
importance  of  task  duration  constraints  in  the  development  of  feasible  schedules.  This  unique 
capability  has  the  potential  to  significantly  improve  the  reliability  and  speed  of  depot 
maintenance  resource  planning,  scheduling,  prediction,  and  performance. 

BAR-CODE  GAME  PLAN 

OC-ALC  plans  to  implement  an  actual  hour  accoimting  system  (using  bar-code  technology)  for 
production  management  to  maintain  an  accurate  picture  of  the  shop  floor  status.  Bar  coding 
equipment  alone,  however,  does  not  ensure  reliable  collection  of  the  data  needed.  What  is  also 
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needed  is  a  strategy  for  best  utilizing  the  bar-cdding  equipment  to  collect  the  needed  data  and  to 
ensure  its  reliability.  The  bar-code  game  plan  defines  a  strategy  for  collecting  shop  floor  data 
using  bar-code  equipment.  The  data  that  will  be  collected  through  the  bar-code  equipment  was 
defined  using  the  IDEFIX  (Semantic  Data  Modeling)  method.  To  identify  what  information  was 
needed,  interviews  were  conducted  with  representatives  from  the  aircraft  division’s  quality, 
production,  engineering/planning,  scheduling,  contracting,  finance,  and  competition 
organizations.  This  information  was  also  compared  with  ProPlan  system  designs.  The 

requirements  for  data  collection  identified  through  these  activities  were  included  in  an  IDEFIX 
model.  This  model  was  then  used  to  develop  a  bar-code  game  plan  and  prototype  database  to 
feed  real-time  status  information  to  ProPlan. 

The  bar-code  game  plan  developments  included  investigations  of  shop  floor  management  issues. 
One  of  the  prevailing  misconceptions  held  hy  production  management,  as  well  as  by  planners,  is 
that  there  should  be  a  high  degree  of  management  exercised  on  maintenance  operation 
performance  to  conform  with  tail-specific  major  job  schedules.  This  notion,  however,  may  not 
only  be  counter-productive,  but  impossible.  For  production  manufacturing  environments,  where 
labor  content  can  be  specified  up  front,  a  high  degree  of  management  may  be  suitable.  This  is 
particularly  true  for  highly  automated  manufacturing  settings.  Additionally,  the  work  units 
developed  for  master  schedule  development,  resource  planning,  and  should-costing  purposes  do 
not  necessarily  reflect  a  structure  well  suited  for  operation-level  management. 

From  a  human  factors  perspective,  it  is  also  important  to  consider  what  level  of  management 
exerted  over  the  mechanic  will  ensure  the  shop  floor  management  systems’  acceptance  and 
success.  Currently,  the  mechanism  for  shop  floor  management  is  the  production  supervisor.  The 
most  promising  systems  strategy  will  be  one  that  emphasizes  assisting  production  supervisors  by 
helping  them  coordinate,  prioritize,  assign,  and  determine  the  current  status  of  work  within  their 
own  areas,  as  well  as  allowing  them  to  have  visibility  on  the  status  of  work  across  the  other 
resource  centers.  This  conclusion  is  motivated  by  an  understanding  of  the  nature  of  production 
maintenance  enviromnents  and  the  varying  management  strategies  available  to  decision-makers. 
Control  strategies  vary  depending  on  the  process  characterization  of  the  current  operating 
environment,  as  depicted  in  Figure  9  below. 

One  management  strategy  is  the  low  management,  low  status  paradigm.  The  current 
environment  at  OC-ALC  is  one  of  low  management,  low  status.  This  is  not  to  say  that  there  is 
no  management  or  no  statusing.  Maintenance  processes  defy  attempts  at  close  management. 
Where  close  management  is  exercised,  it  often  only  serves  to  impose  constraints  that  further  limit 
the  flexibility  and  responsiveness  of  PDM  support  systems  and  processes.  Statusing  mechanisms 
also  exist.  However,  these  statusing  mechanisms  do  not  focus  on  those  items  that  provide  a  true 
indication  of  the  actual  or  projected  factory  state.  Furthermore,  the  status  information  that  is 
available  is  most  often  outdated  or  incorrect  (causing  decisions  to  be  made  with  the  wrong 
information)  and  is  at  too  high  a  level  of  granularity  to  be  of  any  significant  value.  The  result  is 
a  highly  reactive,  chaotic  system. 
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Figure  9 

Management  versus  Status  in  Shop  Floor  Management  Systems 


The  E-3  depot  environment  is  one  that  exhibits  particularly  high  variability  in  the  maintenance 
process.  The  management  and  statusing  strategy  most  appropriate  for  the  depot  maintenance 
environment  is  the  low  management/high  statusing  paradigm.  The  maintenance  processes  are 
too  variable  to  permit  high  levels  of  management.  The  maintenance  process  inherently  relies 
heavily  on  the  use  of  people  to  identify  and  perform  required  maintenance  tasks,  and  controlling 
people  is  inherently  variable.  Imagine  a  situation  where  operation  cards  for  maintenance 
mechanics  are  released  in  a  highly  controlled  manner.  A  mechanic  walks  up  and  requests  an 
operation  to  do;  an  operation  is  dispensed;  the  mechanic  performs  the  operation;  the  mechanic 
reports  having  completed  the  operation  and  requests  his  next  assignment.  Unfortunately,  process 
variability  often  does  not  permit  completion  of  the  operation  (e.g.,  no  part  is  available,  over-and- 
above  work  is  identified).  For  a  high  degree  of  management  to  be  possible,  all  operations  would 
have  to  be  ordered  in  precisely  the  way  that  the  work  will  be  done.  Also,  unpredicted  operations 
introduce  variability  into  the  process.  High  management  in  a  maintenance  environment  would, 
therefore,  prove  futile.  High  statusing,  however,  is  possible.  Currently,  this  is  accomplished 
through  daily  coordination  meetings  held  in  the  morning  and  afternoons  between  shifts.  Change¬ 
over  sheets  provide  status  information  to  subsequent  shifts,  and  crew  chiefs  and  first-line 
supervisors  regularly  provide  status  information  to  production  management  and  each  other. 

The  bar-code  game  plan  was  devised  around  a  low  management/high  statusing  strategy.  As 
such,  it  is  specifically  intended  to  guide  the  development  of  mechanisms  to  make  critical 
indicators  of  current  and  projected  status  more  visible  to  decision-makers. 

PROPLAN  USER  TEST  AND  DEMONSTRATION 

To  provide  a  more  realistic  evaluation  of  ProPlan’s  suitability  for  the  E-3  depot  maintenance 
environment,  a  temporary  link  was  developed  between  ProPlan  and  G037.  This  link  was  used  to 
conduct  live  user  tests  of  ProPlan  with  a  dummy  operation  set. 
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Planners  from  the  E-3  planning  group  conducted  ProPlan  prototype  test  and  evaluation  activities 
over  a  two-week  period.  This  evaluation  effort  included  analyzing  the  planning  functions 
required  versus  those  provided  in  the  prototype,  assessing  ProPlan’ s  ease  of  use  as  compared 
with  current  planning  mechanisms,  evaluating  the  performance  gains  available  for  critical 
planning  functions,  and  determining  the  compatibility  of  the  prototype  with  legacy  systems. 
Planners  were  first  familiarized  with  both  the  planning  paradigm  supported  and  the  mechanisms 
used  within  the  prototype  to  support  planning  functions.  Technology  familiarization 
demonstrations,  software  training,  and  on-site  technical  advisory  support  was  provided  to  support 
these  needs.  User  tests  were  then  conducted,  wherein  actual  planners  tested  ProPlan  using  the 
dummy  operation  set  to  conduct  sample  planning  activities. 

Presentation  of  the  study  results  included  live  demonstrations  at  OC-ALC  using  Air  Force 
planners  to  operate  the  prototype  system.  Some  of  the  comments  made  by  these  planners  in 
describing  ProPlan  are  as  follows. 

When  asked  how  well  ProPlan  serves  to  provide  visibility  of  existing  resources  (e.g.,  manpower, 
facilities,  equipment/tools,  materials),  Dwight  Van  Meerveld,  an  E-3  planner,  stated  that  ProPlan 
will  improve  the  accuracy  of  projected  resource  and  material  needs  and  produce  significant, 
measurable  benefits,  particularly  since  they  do  not  have  this  capability  now.  Mr.  Frank  Cannon, 
another  E-3  planner,  noted,  “During  operation  building  or  editing,  we  have  a  direct  look  at  each 
item  during  the  development  of  any  operation.  This  saves  going  to  different  files  for  the  same 
information.” 

Participating  planners  were  also  asked  how  effective  ProPlan  is  in  reducing  the  amount  of  time 
required  to  identify  and  assemble  the  operations  to  be  performed  on  a  specific  aircraft. 
Furthermore,  they  were  asked  how  good  a  job  ProPlan  does  to  reduce  the  opportunity  for  error  in 
performing  this  planning  task.  Frank  Cannon  commented  that  ProPlan  supported  his  planning 
activities  “very  well,”  as  demonstrated  by  its  ability  to  virtually  eliminate  the  chance  for  error  in 
selecting  tail-specific  operations.  He  continued,  “Once  the  operations  are  assigned  to  a  task,  all 
that  remains  is  for  engineering  to  identify  the  requirement  to  a  specific  tail.  At  present,  after  the 
engineer  assigns  tail-specific  tasks,  planning  must  select  the  configuration  code  and  work 
category  code,  and  assign  each  to  the  specific  tail.  This  is  currently  a  time-consuming  and 
mistake-prone  process.” 

Planners  were  impressed  by  how  well  ProPlan  facilitates  the  maintenance  and  continuous 
improvement  of  operation  definitions.  More  specifically,  they  tested  how  well  ProPlan  supports 
the  annual  maintenance  of  operation  set  data  through  the  use  of  rapid  search,  retrieval,  and 
review  of  operations  by  responsible  planners.  Dwight  found  that  ProPlan  is  “much,  much  better 
than  [what]  we  currently  use,”  and  estimated  that  “maintaining  operations  with  [ProPlan]  will 
reduce  [non- value-added]  time  about  20  to  40  percent.”  Dwight  further  noted  that  “  [ProPlan’ s] 
definitized  list  feature  will  save  on  the  order  of  100  times  the  effort  required  using  previous 
methods.” 

These  comments  are  representative  of  those  made  by  planners  who  participated  in  the  user  test. 
The  support  provided  to  two  other  key  ProPlan  users  (i.e.,  engineers  and  schedulers)  was  not 
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tested  during  this  phase  of  user  testing.  Since  both  of  these  roles  represent  key  interfaces  to 
planning,  more  thorough  tests  of  ProPlan’s  support  for  these  roles  is  recommended.  ProPlan  not 
only  provides  support  for  these  role  types  that  is  largely  non-existent  in  today’s  system,  but  it 
also  provides  a  unique  paradigm  for  integrated  requirements  definition,  planning,  and  scheduling 
that  may  be  coupled  with  a  new  generation  of  statusing  systems  to  provide  a  closed-loop  PDM 
support  system  solution.  The  primary  focus  of  the  ProPlan  test,  however,  was  on  its  planning 
support.  The  results  of  that  test  indicate  that  ProPlan  helps  planners  do  their  job  better,  faster, 
and  easier  with  increased  visibility,  detail,  and  accuracy  over  what  is  currently  in  use.  The 
attitude  of  planners  is  best  summarized  by  their  section  chief,  Mr.  Dan  Mooney.  When  speaking 
of  ProPlan,  he  simply  comments,  “My  people  want  it.” 

Some  accomplishments  are  reflected  in  Table  3.  These  accomplishments  reflect  measurable 
benefits  that  were  estimated  by  OC-ALC  based  on  their  testing  of  the  prototype  software 
products  of  this  effort. 


Table  3.  Goals,  Metrics,  and  Benefits 


Goal 

Metric 

Measurable  benefits 

Reduce  PDM  cycle 
time. 

Cycle-time  losses  through 
duplication  of  effort  and  lost 
economies. 

Dispatch-based  schedule- 
simulation  mechanism 
automatically  translates  plarmer- 
defined  operation  precedence 
constraints  into  candidate 
schedules  that  eliminate  unplanned 
duplicate  operations  and  maximize 
productive  use  of  resources. 

Frequency  of  unproductive 
resource  utilization  caused  by 
resource  unavailability. 

When  provided  with  visibility  of 
current  resource  status, 
demonstrated  the  ability  to  rapidly 
regenerate  both  operation  and 
resource  schedules  to  maximize 
productive  resource  utilization. 

Improve 

responsiveness  of 
PDM  support 
processes. 

Time  to  perform  planning 
activities. 

Two-day  manual  effort  to  select 
tail-specific  operations  reduced  to 
minutes;  opportunity  for  error 
reduced  by  an  order  of  magnitude. 

Overnight  print-check  cycle 
required  for  planning  data 
maintenance  and  quality  assurance 
eliminated;  improved  user  interface 
provides  an  additional  50%  cycle 
time  reduction  for  routine  planning 
tasks. 
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Table  3.  Goals,  Metrics,  and  Benefits  (continued) 


Time  to  perform  what-if  analyses 
of  workload  and/or  schedule 
changes. 

Cross-aircraft  schedule  simulation 
set-up  time  reduced  from  200  man¬ 
hours  to  minutes;  ripple  effect  of 
scheduling  changes  on  other 
aircraft  produced  in  1  hour  versus 
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Accuracy  of  schedule  projections. 

Finite  capacity  schedule  generation 
capability  that  can  account  for  all 
resources  (the  current  system  is 
only  capable  of  considering  the 
skill  resource);  extended  current 
system’s  ability  to  perform 
deterministic  schedule  projection 
with  a  stochastic  schedule 
simulation  capability. 

Reduce  the  number 
of  discrepancies 
during  the  final  post¬ 
dock  test. 

Provisions  for  continuous 
improvement  of  operation 
definitions. 

Annual  maintenance  of  operation 
set  data  supported  by  rapid  search, 
retrieval,  and  review  of  operations 
by  responsible  planner;  extensible, 
context-sensitive  help  facilities 
provide  on-line  mechanisms  to 
capture  and  convey  good  operation 
design/redesign  practice;  replaced 
definitive  list  editing  done  “in  the 
blind,”  line  by  line  replaced  with 
full  page  Microsoft  Word  text 
editing  facilities. 

Reduce  the  amount 
of  unplanned, 
unscheduled,  and 
over-and-above  tasks 
in  the  PDM  process. 

Number  and  frequency  of 
scheduler  requests  for  planners  to 
incorporate  major  jobs  in  tail- 
specific  plans  that  were 
inadvertently  overlooked. 

Total  elimination  of  such  requests 
through  automatic  selection  of  tail- 
specific  operation  sets  based  on  the 
Work  Specification  tasks  called  for 
in  the  work  order  (i.e.,  transcription 
errors  eliminated). 

Percent  over-and-above  (O&A) 
operations  maintained  in  planning 
system  for  future  planning 
activities. 

Possibly,  100%  maintenance  of 

O&A  operations  (current  system 
allows  planners  to  define  but  not 
maintain  O&A  operation  data). 
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SUMMARY  OF  ACCOMPLISHMENTS 


The  accomplishments  of  this  effort  are  divided  into  two  categories.  The  first  category  lists  goals 
accomplished.  The  second  category  lists  long-term  goals,  a  representative  set  of  candidate 
metrics  for  assessing  relative  progress,  and  some  measurable  benefits  in  terms  of  those  metrics 
that  may  be  realized  through  adoption  and  use  of  the  demonstrated  system  concepts. 

Some  of  the  achieved  goals  are  shown  in  the  following  list. 

1 .  Demonstrated  the  relevance,  utility,  and  payback  potential  of  the  IDEF3  Process 
Description  Capture,  IDEF5  Ontology  Description  Capture,  and  IDEF9  Business 
Constraint  Discovery  methods. 

2.  Developed  the  prototype  ProPlan  system,  which  is  a  multi-user,  client/server,  network 
application  that  makes  extensive  use  of  COTS  software. 

3.  Produced  a  prototype  E-3  shop  floor  database,  together  with  a  set  of  screens  and  reports 
characteristic  of  the  E-3’s  shop  floor  information  system  needs. 

4.  Developed  the  Stochastic  Resource  Requirements  Projector  (SRRP),  which  provides  a 
self-maintaining,  operation-level  simulation  model  supporting  multi-aircraft,  finite 
capacity  schedule  generation  and  testing.  The  SRRP  demonstrated  the  ability  to 
generate  candidate  schedules  rapidly  to  accommodate  required  changes  or  to  support 
contingency  planning  and  what-if  analyses  in  a  design  of  experiments  setting.  This  was 
one  of  the  most  significant  innovations  of  the  project. 
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RECOMMENDATIONS 


These  projected  benefits  can  only  be  realized  through  actual  implementation.  Before  moving 
forward  to  full  implementation,  however,  we  recommend  first  conducting  a  pilot  test  of  ProPlan. 
ProPlan  offers  a  unique  set  of  capabilities  that  today’s  systems  either  do  not  provide  or  do  not  do 
well.  The  ProPlan  prototype  was  used  to  successfully  demonstrate  the  need  for  these  advanced 
capabilities  and  to  underscore  the  importance  of  systems  designed  explicitly  for  the  production 
maintenance  environment.  Without  more  extensive  and  realistic  testing,  however,  the  ProPlan 
prototype  cannot  be  adequately  proven  to  work  as  intended  in  all  planning  situations. 

The  purpose  of  the  pilot  test  effort  would  be  to  conduct  a  realistic,  live  test  of  the  ProPlan 
prototype  planning  support  system  as  a  candidate  for  full  implementation.  As  a  complementary 
extension  to  the  ProPlan  prototype  user  test  and  demonstration  effort,  the  pilot  test  would  afford 
systems  planners,  developers,  and  researchers  the  opportunity  of  testing  the  long-term  effects  of 
ProPlan  system  implementation  on  PDM  and  PDM  support  process  performance. 

Among  the  tasks  that  would  be  performed  as  part  of  the  pilot  test  are  the  following: 

1 .  Debug  and  throughly  test  the  ProPlan  prototype. 

2.  Validate  the  SRRP  simulation-based  approach  for  schedule  testing  and  generation. 

3.  Implement  and  operate  the  ProPlan  pilot  system  parallel  to  existing  systems. 

4.  Monitor  the  performance  of  ProPlan  (particularly  in  anomalous  situations). 

5.  Determine  what  changes,  if  any,  would  be  required  to  support  ProPlan  implementation 
across  PDM  lines. 

6.  Maintain  currency  of  the  ProPlan  models  and  a  log  of  lessons  learned  to  support  future 
implementation  activities. 
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SUMMARY 


The  IICE  technology  demonstration  effort  conducted  at  OC-ALC  produced  a  prototype  planning 
system  (ProPlan)  that  embodies  a  wide  range  of  process  improvements.  These  process 
improvements  were  identified  through  the  application  of  the  IICE  IDEF3  Process  Description 
Capture  and  IDEF5  Ontology  Description  Capture  methods.  The  improvements  identified  using 
these  methods  were  used  to  drive  the  prototype  development  effort.  For  example,  planners 
currently  select  the  operations  to  be  applied  to  a  specific  aircraft  manually  and  then  transcribe 
those  selections  to  the  dispatching  component  of  G037E.  ProPlan  could  shorten  this  two-day 
effort  to  minutes  and  reduces  the  potential  for  error.  In  addition  to  saving  planners  time  and 
effort,  this  feature  of  ProPlan  could  entirely  eliminate  the  need  for  schedulers  to  check  the 
thousands  of  operations  dispatched  to  the  shop  floor  for  any  operations  that  may  have  been 
inadvertently  left  out.  Another  product  of  the  effort  was  the  Stochastic  Resource  Requirements 
Projector  (SRRP).  This  tool  uses  planning  data  in  ProPlan  to  produce  an  operation-level 
simulation  model  supporting  multi-aircraft,  finite  capacity  schedule  generation,  and  testing.  If 
implemented  with  ProPlan,  the  SRRP  could  be  used  to  generate  candidate  operation-level 
schedules,  to  support  contingency  planning,  and  to  conduct  what-if  analyses. 

The  IICE  methods  provided  an  efficient  means  to  successfully  demonstrate  a  model-driven 
approach  to  systems  analysis,  design,  and  development.  IDEF3  proved  its  versatility  and  power 
as  a  process  description  capture  mechanism.  IDEF5  and  IDEFl  were  also  used,  providing 
important  insights  on  domain-specific  terminology,  experience-based  knowledge,  and 
information  sharing  needs  among  planners,  schedulers,  and  maintenance  technicians.  Although 
used  in  a  relatively  formative  stage,  IDEF9  helped  the  contractor  team  identify  business 
constraints  that  impacted  planning  activities  (e.g.,  material  acquisition  constraints).  These 
methods  were  used  in  a  model-driven,  rapid  application  development  approach  to  produce  the 
ProPlan  prototype.  The  technology  used  to  support  this  approach  included  IDEF  modeling  tools, 
component-based  software  development  environments,  client/server  technology,  and  a  number  of 
COTS  software  components. 

Ultimately,  however,  the  full  benefit  of  these  technological  solutions  could  only  be  realized  by 
carrying  the  work  that  was  begun  toward  full  implementation.  For  many  routine  planning 
activities,  ProPlan  could  provide  a  50%  reduction  in  the  time  and  effort  required  of  planners. 
ProPlan  also  provides  extensive  database  storage,  search,  and  retrieval  capabilities  enabling 
maximized  reuse  of  previously  developed  planning  data.  This  feature  could  reduce  planning 
workload  as  much  as  10  to  20%  by  eliminating  the  need  to  recreate  plans  for  low-percent 
operations.  Noting  these  and  other  benefits  of  a  ProPlan  solution,  implementing  ProPlan  could 
improve  the  speed,  reliability,  and  ease  with  which  planning  tasks  are  performed. 

Before  moving  forward  to  full  implementation  at  OC-ALC,  however,  we  recommend  first 
conducting  a  pilot  test  of  ProPlan.  Pilot  testing  would  be  used  to  examine  the  ProPlan  prototype 
in  a  realistic  setting  as  it  is  applied  to  the  full  range  of  planning  situations.  Pilot  testing  would 
also  provide  the  data  needed  to  determine  ProPlan’ s  true  payback  potential  at  both  the  planning 
and  PDM  levels. 
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